Qualcomm a levé le voile sur son Snapdragon X Plus, une version moins puissante que l’Elite, mais également moins onéreuse. Alors que cette ligne de puces doit permettre enfin l’avènement des machines Windows sur puces Arm, faisons un rappel sur les enjeux.
C’est peu dire que des puces Arm performantes sont attendues dans le monde Windows. Difficile d’oublier les tentatives sur Windows RT et Windows 10. Depuis, des machines existent bien – notamment une déclinaison de la tablette Surface – mais le problème est à chaque fois le même : les performances.
On le sait, quand une application arrive sur Windows on Arm dans une version compilée spécifiquement pour cette architecture, les performances font un énorme bond. Google l’a rappelé récemment pour son navigateur Chrome, qu’il a pris le temps (c’est un euphémisme) de peaufiner. La firme de Mountain View s’est probablement dit qu’il n’était pas question de rater le coche sur la prochaine génération d’ordinateurs portables et tablettes devant embarquer les Snapdragon X.
Dans le cas d’une application non compilée pour Arm, c’est l’émulation x86 qui prend le relai. Et là, le résultat est très différent, particulièrement dans les applications lourdes. La couche d’émulation fournie par Microsoft n’est pas aussi efficace que Rosetta chez Apple. Bien que l’arrivée des puces de Qualcomm soit très attendue, elles ne règleront pas ce point d’un coup de baguette magique.
Et voilà le Snapdragon X Plus
Abonnez-vous pour tout dévorer et ne rien manquer.
Déjà abonné ? Se connecter
Commentaires (12)
#1
https://www.semiaccurate.com/2024/04/24/qualcomm-is-cheating-on-their-snapdragon-x-elite-pro-benchmarks/
Si cela est avéré, c’est encore un moment « PC on ARM » qui fera pschit …
#2
Il y a tellement d’applications et d’éditeurs sur Windows que la marche forcée (un peu en mode Apple) n’est pas vraiment possible.
Pondre un ultrabook, en ARM qui est juste destiné à faire du Office et Web principalement (donc sur des applis ARM), on devrait quand même arriver vite à de bonnes perfs et une bonne autonomie. Je suis curieux de voir ces Snapdragon dans une machine.
Le temps d’arriver à un émulateur X86 performant par contre je doute que ce soit si simple, aussi puissant soit les processeurs ARM. A mon avis Windows va avoir le c entre deux chaises un très long moment…
Ce serait intéressant d’avoir une notion de tarifs, je sens bien le prix moins élevé qu’un i7 mais la machine 2 fois plus cher à l'achat
#2.1
Mais un problème sous-jacent, c'est que pour le moment sans extension spécifique, émuler un x86 nécessite d'utiliser des pages de 4ko de mémoire.
Or, c'est aussi contre performant actuellement.
Donc:
* soit on peut émuler du x86
* soit on gagne (jusqu'à 15%) en perfs.
#2.2
On parle ici d'émuler un du x86 non pas pour faire tourner un OS dessus mais simplement une application. J'ai l'impression que les pages de 4ko sont un non sujet ici, mais il y a peut-être un truc qui m'échappe. Pour moi, la gestion des pages, c'est l'OS qui le fait avec la gestion de la MMU et ensuite des exceptions qui font charger la page si les données ne sont pas en mémoire. Une application ne gère pas elle-même la pagination et donc l'émulateur n'a donc pas non plus besoin de la gérer.
#2.3
Sous Linux : Huge Page.
En pratique, quand j'ai besoin, j'utilise mmap et madvise. L'intêret est de ces grandes pages est de pouvoir réduire la pression sur le TLB, un cache mémoire en charge de faire le lien entre mémoire virtuelle et physique. Pour certaines applications (notamment BDD, traitement de fichiers de grands volumes ou encore calculs), ce genre d'optimisations permet d'améliorer les performances de, facilement, quelques dizaine de pourcents comme indiqué par @Wosgien.
Historique des modifications :
Posté le 25/04/2024 à 18h49
Une application peut demander recourir à des pages plus grandes sur l'x86_64 tel que 2 MiB et 1GiB par exemple. Évidemment l'OS doit pouvoir gérer ces situations.
Sous Linux : Huge Page.
En pratique, quand j'ai besoin, j'utilise mmap et madvise. L'intêret est de ces grandes pages est de pouvoir réduire la pression sur le TLB, un cache mémoire en charge de faire le lien entre mémoire virtuelle et physique. Pour certaines applications (notamment BDD, traitement de fichiers de grands volumes ou encore calculs), ce genre d'optimisations permet d'améliorer les performances de, facilement, quelques dizaine de pourcents.
#2.4
Ces librairies peuvent être assez bas niveau.
Il y a des applis "bateau" qui peuvent être recompilées sans problème, mais elles sont très rares. Même des librairies XML ont du mappage de fichier en RAM, ce qui nécessite un accès à l'OS. Et beaucoup sont compilées avec des limites de 4ko "en dur", tout simplement parce que la taille de page est indiquée dans les scripts de compilation (en se disant que si on devait aller sur un autre OS, il "suffirait" de recompiler).
La plupart des émulateurs haut-niveau ont tout de même un lien fort à l'OS, ou alors il faut réécrire tous les appels - et même là, rien n'est garanti, on peut facilement tomber sur un bout de code qui alloue 4ko et détecte de lui-même les exceptions lors d'un dépassement de page (anti-virus ... anticheat?)
Et détecter les dépassement de page "à la main" parce que le système a des pages plus grandes est très coûteux.
Bref, sans des pages de même taille, ou sans un CPU qui peut gérer en même temps des pages de 4k et 16k/64k, aucune garantie possible de compatibilité des softs.
#3
Quelqu'un a une ou des vidéos qui vulgarise bien l'interaction cpu, os, pages, mémoire, (et un peu compilation, mais sur ce dernier, je commence à être en terrain connu) ? Siouplé :)
#3.1
En fait, l'OS présente un espace mémoire à chaque appli. Cet espace mémoire semble contigu, mais l'OS le découpe en morceaux de 4k (lié à ce que le CPU sait gérer). Chaque fois que l'application veut lire en mémoire, il faut vérifier dans quel morceaux de 4k cela tombe, si ce morceaux est en mémoire ou sur le disque, si l'application a le droit d'y lire, écrire, ...
Donc quand on parcourt un tableaux, tous les 4k l'appli est interrompue pour que l'OS vérifie tout cela, fasse en sorte que la mémoire soit là, ...
Quand on fait du traitement de données et qu'on tape partout dans la RAM, on est interrompu plein de fois, mais heureusement le CPU a des mécanismes pour que les pages les plus récentes soient plus rapides à accéder.
C'est normalement transparent pour une appli lambda.
Le problème, c'est que 4ko, c'est trop juste maintenant. On a des mécanismes pour avoir des pages plus grandes, mais c'est très spécifique à certaines applis et ça demande de taper dans l'OS: on est moins portable.
Une solution serait de passer à des pages de 16ko, 64ko. C'est possible sur certains ARM, à ma connaissance pas sur PC, et c'est déjà un boost pour le traitement (y compris pour le javascript).
Par contre, quand on fait de l'émulation, certaines fonctionnalités pointues sont liées à ces pages, et les limites sont souvent compilées dans le code, impossibles à retrouver. Donc un soft très optimisé comme un jeu, une BDD, risque de ne pas fonctionner sur un OS dont les pages sont de taille différente.
Emuler la détection de ces limites est extrêmement coûteux (cela revient à checker logiciellement chaque accès mémoire...)
Pour résumer:
* Un passage du x86 à l'ARM avec la même taille de page: on peut émuler sans trop se poser de questions
* Un passage du x86 à l'ARM avec un taille de page inférieure: on peut émuler sans trop se poser de questions, mais on perd en perfs
* Un passage du x86 à l'ARM avec un taille de page supérieure: on peut émuler des trucs simples ... mais il y a des limites, des risques, mieux vaut se focaliser sur le natif et les runtimes type Java/C#
#3.2
#4
Reste à voir l'approche tarifaire qu'il y aura autour, mais à mon avis il va pas falloir qu'ils s'emballent trop pour pas que tout ça parte en échec commercial.
#5
Si oui c'est là où ça va causer, sous Linux (ou tout soft open source en général) il suffit de recompiler, pour avoir les perfs optimales.
#5.1
C’est d’ailleurs une des raisons qui entraîne la fin du support des téléphones Android : puisque le pilote n’est pas mis à jour, il n’est pas possible de passer sur le noyau plus récent de la nouvelle mouture (les ROM alternatives trafiquent souvent Android pour le faire tourner avec l’ancien noyau).
C’est aussi pour ça que Fairphone n’a pas choisi un processeur Snapdragon pour son numéro 5 mais une version destinée à l’IoT/l’industrie pour avoir un support plus long.
(*) Pas certain que ce soit le bon terme, les sachants peuvent corriger.
Historique des modifications :
Posté le 28/04/2024 à 13h06
Il y a des pilotes open source pour un certain nombre d’éléments (la micro-architecture ARMv8 est publique donc GCC et consorts s’en sortent sans problème, la partie graphique est basée sur l’architecture Radeon—dont Adreno est une anagramme—donc il y a peut-être quelque-chose aussi) mais il reste beaucoup d’éléments qui n’ont aucune solution open source.
C’est d’ailleurs une des raisons qui entraîne la fin du support des téléphones Android : puisque le pilote n’est pas mis à jour, il n’est pas possible de passer sur le noyau plus récent de la nouvelle mouture (les ROM alternatives trafiquent souvent Android pour le faire tourner avec l’ancien noyau).
C’est aussi pour ça que Fairphone n’a pas choisi un processeur Snapdragon pour son numéro 5 mais une version destinée à l’IoT/l’industrie pour avoir un support plus long.